Summary

Adds an optional openapi-max-workers input to component-service-profile-kotlin.yml. It maps to ./gradlew --max-workers=<n> for the OpenAPI build step only. Defaults to empty — no behavior change for any existing caller.

Motivation

monta-app/service-api-gateways has been failing every recent production deploy in the Update Service Profile / Build OpenAPI spec step. The pattern is identical across runs:

> Task :portal-api:kaptKotlin
##[error]The runner has received a shutdown signal. ...
##[error]Process completed with exit code 143.

Three example runs:

• 25171374143 (Apr 30, manual prod deploy — failed mid-build)
• 25236336830 (May 1, partner-api staging)
• 25236336844 (May 1, portal-api production)

All three die ~50s after portal-api:kaptKotlin starts, with several other modules' kaptKotlin tasks running concurrently. Exit code 143 is SIGTERM — the kernel OOM-killed the worker JVM. Each kapt worker uses -Xmx4096m; with 4–8 in flight on linux-arm64, peak memory blows past the runner's available RAM.

Why a configurable input rather than hardcoding --max-workers=2

Other Monta repos using this shared workflow are single-module Micronaut services (service-vehicle, service-energy, service-audit-log, etc.) and have no parallelism contention to begin with. Hardcoding a cap would be a no-op for them functionally but a poor signal — so this PR keeps existing repos' behavior bit-for-bit and lets the affected repo opt in.

Diff

+      openapi-max-workers:
+        required: false
+        type: string
+        default: ''
+        description: |
+          Optional cap on Gradle parallelism for the OpenAPI build step.
+          ...

       - name: Build OpenAPI spec
         shell: bash
         env:
           GHL_USERNAME: ${{ secrets.GHL_USERNAME }}
           GHL_PASSWORD: ${{ secrets.GHL_PASSWORD }}
+          OPENAPI_MAX_WORKERS: ${{ inputs.openapi-max-workers }}
         run: |
-          ./gradlew "$GRADLE_TASK"
+          if [ -n "$OPENAPI_MAX_WORKERS" ]; then
+            ./gradlew --max-workers="$OPENAPI_MAX_WORKERS" "$GRADLE_TASK"
+          else
+            ./gradlew "$GRADLE_TASK"
+          fi

Caller-side change (separate PR in service-api-gateways)

After this lands, the four deploy workflow files in service-api-gateways (one per API) gain:

update-service-profile:
  uses: monta-app/github-workflows/.github/workflows/component-service-profile-kotlin.yml@main
  with:
    ...
    openapi-max-workers: '2'

Trade-off for that repo: roughly 30–60s slower OpenAPI step (worth it vs. failed deploys).

Out of scope

This PR only addresses parallelism in the Build OpenAPI spec step of this single shared workflow. Other workflows (test, lint, build, deploy) are untouched. Other gradle invocations in this same workflow are untouched (the Discover annotation processor step uses a much lighter tasks --all query).

🤖 Generated with Claude Code